Description Of Fixes

This request fixes an addresses multiple security vulnerabilities related to Server-Side Request Forgery (SSRF) and unvalidated user input handling across several files within the FlowiseAI codebase. These issues could allow attackers to manipulate outgoing requests, access unintended internal resources, or exploit type confusion to bypass sanitization logic. Each fix introduces proper input validation, allow-list enforcement, and type-safety improvements to ensure robust protection against such threats.

1. Secure Tenant ID Validation in Azure SSO

• packages/server/src/enterprise/sso/AzureSSO.ts The testSetup static method previously allowed unvalidated user input (tenantID) to control the hostname in an outgoing HTTP request to Microsoft Azure.
  This could enable SSRF attacks by redirecting requests to unintended endpoints or internal services.

Fix implemented:

• Added strict validation logic for tenantID before constructing the authentication URL.
• Only accepts tenant IDs that match valid Azure formats:
  • A UUID/GUID pattern, or
  • A domain ending with .onmicrosoft.com.
• Invalid or malformed inputs are rejected early, preventing any outbound requests.
• Introduced a helper validation function to ensure DRY and clarity.

2. Outbound Request Allow-List for Secure Fetch

• packages/components/src/httpSecurity.ts Previously, user-supplied URLs were used directly in outbound HTTP requests, protected only by a deny-list. This approach left room for bypass attacks or indirect SSRF through redirects.

Fix implemented:

• Introduced a positive allow-list mechanism for all outbound requests.
• Added a new function to validate URLs or hostnames against a configurable allow-list.
• Integrated this validation within the secureFetch function for both the initial URL and all redirects.
• Added support for a new environment variable, HTTP_ALLOW_LIST, defining a comma-separated list of allowed domains or wildcard patterns (e.g., *.example.com).
• Restricted allowed protocols to http and https only.
• Maintained compatibility with existing deny-list checks for defense in depth.

3. Validation of Chatflow IDs in Evaluation Service

• packages/server/src/services/evaluations/index.ts The service previously used unvalidated chatflowId values to construct request URLs, creating a potential SSRF vector if arbitrary IDs were supplied.

Fix implemented:

• Added strict validation for chatflowId before executing EvaluationRunner.runEvaluations.
• Verified that all provided IDs exist in the ChatFlow database.
• Rejected any non-existent or malformed IDs (e.g., containing unexpected characters or path traversal patterns).
• Enforced validation before any data is passed to the evaluation logic.
• Optionally restricted the ID format to UUIDs for consistent integrity.

4. Type-Safe Validation for Feedback Parameters

• packages/server/src/controllers/chat-messages/index.ts Certain query parameters (feedbackType) were assumed to be strings but could be arrays due to crafted malicious requests. This type confusion could bypass sanitization logic.

Fix implemented:

• Added a type guard function to safely validate and normalize feedbackType parameters.
• Ensured that only recognized ChatMessageRatingType enum values are accepted.
• Converted non-string or unexpected array values into a sanitized format before further use.
• Applied this validation directly in the controller to ensure all downstream components receive clean and typed data.

5. Runtime Type Enforcement for Storage Prefix Parameters

• packages/components/src/storageUtils.ts Unvalidated prefix parameters could cause unsafe string operations or logic errors if arrays or non-string types were passed in.

Fix implemented:

• Added runtime type checks to ensure prefix is always a valid string before operations like substring or concatenation.
• Implemented this check within _cleanEmptyS3Folders for minimal code impact and maximum safety.
• Non-string inputs are either converted to strings or safely rejected before any file operations.

These changes collectively harden the application against:

• Server-Side Request Forgery (SSRF)
• Improper Input Validation and Type Confusion
• Unsafe Outbound Network Requests
• Potential Data Leakage or Unauthorized Internal Access

All fixes follow the principle of defense in depth, ensuring that user inputs are validated, sanitized, and restricted at the earliest possible stage.

• Verified all modified modules compile and function correctly.
• Confirmed that all validation paths properly reject malformed inputs.
• Manually tested tenant ID, feedbackType, and chatflowId validation against both valid and invalid data.
• Validated that the allow-list enforcement in secureFetch correctly blocks disallowed domains.

Additional Notes

• Configuration for HTTP_ALLOW_LIST can be provided via environment variables or config files.
• All fixes are backward-compatible and do not alter existing expected functionality for legitimate users.
• These patches improve overall security hygiene and conform to best practices for secure input handling and outbound request control.